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In 1978, it was decided that USC should actively pursue obtaining the 
hardware/software necessary to do image processing and the classifica- 
tion of Landsat data. At that time, USC computer services was heavily 
committed to the maintenance and development of its graphics capabili- 
ties and it was felt that the landcover data available through Landsat 
would be a useful compliment to other data (soils, census data, politi- 
cal boundaries, roadways, climate), that was being collected. Some 
state agencies had contracts, notably with Stanford and ERL, to do 
specific projects along these lines and it was felt that USC could 
better meet the needs of the state locally. 


A Data General Eclipse Model S/230 mini-computer originally purchased 
for another purpose was now dedicated to graphics. After suitable 
modifications, i.e., the additions of a large disk drive, dual density 
tape drive and an image processing display device, the minimum hard- 
ware necessary to do image processing and classification of Landsat 
data was in place. 


Simultaneously, the task of obtaining a suitable software package to do 
the calculations necessary to this type of work was undertaken. Several 
systems were originally considered until it was decided that The Earth 
Resources Laboratory (ERL) software would best fit the needs of USC. 
Under their technology transfer program, ERL supplied a copy of the 
software then being used at Slidell, Louisiana as well as the promise 
of help in setting it up. 


Since no new contracts involving the use of these capabilities were 
pending, it was felt that USC could afford to spend the time setting 
up the system and tailoring it to fit individual needs. Hardware con- 
siderations demanded a FORTRAN based mini-computer system. Shop policy 
demanded source listings and documentation. Cost involved the manhours 
and travel necessary to learn and implement the system. The source 
software was supplied free of charge under the technology transfer pro- 
gram. 


Implementation of the system proceeded satisfactorily. In October, 1979, 
it was semi-operation (i.e., a scene could be reformed, searched, clas- 
sified and grouped). At this time, in a routine visit to Bay Street - 
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Mississippi, ELAS was . introduced.. After judging its merits versus those 
of the earlier system, it was decided to implement ELAS. A major factor 
in this was the disclosure that ERL would no longer support the old sys- 
tem once ELAS was totally operational. There was a little difficulty 
implementing a couple of key modules (namely programs to overlay 2 dif- 
ferent scenes and the program to geographically reference a classified 
scene). It was felt that USC could get ELAS up and implement the over- 
lay and georeference overlays in only a little more time than it would 
have taken to implement the old modules. (Hindsight shows this judge- 
ment correct) . 


In March, 1980, the image display device arrived and shortly thereafter, 
USC produced a general landcover map of South Carolina using a hybrid 
system. The Landsat scenes that made up the map were reformatted, 
searched and classified under the old modular system but were georefer- 
enced, displayed and grouped into landcover types using ELAS. The in- 
dividual scenes were then merged into the state data base grid on the 
universities’ mainframe. A tape was subsequently prepared from which 
the map was produced. 


ELAS is now fully operational at USC. The latest project involving the 
classification of Greenville County in South Carolina was done from 
Landsat tapes to overlay to final landcover classification on a UTM 
coordinate grid, entirely by ELAS. 


Throughout the implementation procedure, ERL willingly answered questions 
and supplied, if available, updated programs and documentation when 
asked. However, the entire task of implementing ELAS was essentially 
done by USC. This was done partly out of preference, but mostly out of 
necessity since the Data General Eclipse used by USC is not directly 
compatible with the Interdata upon which ELAS was developed at ERL. 


Hardware differences include the use of 16 bit word versus a 32 Bit word. 
The smaller addressability results in less space being available for 
program overlays. This necessitated cutting down some array sizes as 
used at ERL. The DG Eclipse does not support INTEGER*4 arithmetic which 
is used extensively throughout the ELAS package. This was rectified by 
changing all INTERGER*4 variables to REAL and watching for places where 
floating point arithmetic cannot be used. To date, the resultant loss 
of significance has not proved to be a problem. 


These problems, however, were minor compared to the main task of inter- 
facing the ELAS software to Data General’s FORTRAN callable runtime 
routines. Hence USC had to write its own versions for many of the 
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subroutines. Notable among them were the subroutines that handle in- 
put /output and those that bring in the various overlays. 


Every machine handles I/O in its own way. Thus, the packages handling 
tape I/O, disk I/O, terminal I/O and Comtal I/O had to be developed 
locally. This is a major but unavoidable undertaking when implementing 
software on any machine not exactly identical to the machine on which 
the software was developed. ELAS does however use general I/O subrou- 
tines which contain most of the machine dependent calls making this 
task a little easier. These were totally re-written locally and all the 
programs linked so that those routines are always resident. 


Once the resident section of code was complete, implementation of the 
individual overlays proceeded fairly easily. However, each overlay did 
need to be debugged and tested to check for things such as array size 
and INTEGER*4 arithmetic. The overlay structure of ELAS is such that 
this can be done without any undo effects on the other overlays. Also, 
each overlay is linked separately so that the entire ELAS package does 
not have to be re-linked every time a new overlay is introduced. 


There is, however, one time when every overlay does need to be re-linked. 
That is when a change is made in any of the routines that are always resi- 
dent. Then every overlay has to be re— linked and re-checked for unfore- 
seen effects. This however, is more prevalent early on when the problems 
that occur are likely to be those of the resident routines and structure. 
Once these stabilize, the implementation of any individual overlay is 
relatively straight forward. At this time, users can write and imple- 
ment their own overlays without any undue problems. 


In general, ELAS is an extremely flexible and workable system for pro- 
cessing Landsat type data. This very flexibility, however, is both its 
strength and its weakness. In order to make full use of ELAS, the people 
using it need to have a thorough understanding of it and what they are 
trying to do. This precluses outside users from working with the system 
by themselves. Normally, one of our staff works in conjunction with an 
outside user to produce the product desired. 


User documentation is extensive, relatively reliable for such a new 
system, but takes an understanding of the system in order to use effec- 
tively. ELAS is available through NASA’s Technology Transfer Program 
and the version to fit a Data General Computer is available from USC. 


ELAS is a good and flexible tool and recommended for any user who can 
invest time and money for full utilization. 
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